Data unit transmission method and device

ABSTRACT

A method of controlling a transmission of data units arranged in accordance with a predetermined communication protocol over a plurality of network entities, said network entities operating according to said predetermined communication protocol, from a sending network entity to a receiving network entity over one or more forwarding network entities, comprising providing in a data unit a first data field arranged to contain network entity identification information, said first data field being different from a forwarding data field designated by said communication protocol to contain information to be used by forwarding network entities for forwarding said data unit to the receiving network entity, said first data field being defined such that a given network entity that reads the first data field can at least make a decision on the basis thereof whether said given network entity is identified or not, and in said one or more forwarding network entities, performing a data unit processing operation after receiving said data unit, which comprises reading said first data field and making an identification decision on the basis thereof whether the forwarding network entity performing said data unit processing operation is identified or not.

FIELD OF THE INVENTION

The present invention relates to method of controlling a transmission ofdata units arranged in accordance with a predetermined communicationprotocol from a sending network entity over at least one forwardingnetwork entity to a receiving network entity, and also relates to thecorresponding network entities and methods of controlling these networkentities.

BACKGROUND OF THE INVENTION

In the field of data communications, it is known to transmit data from asender to a receiver in the form of data units, where each data unitcontains some form of appropriate information that lets forwardingnetwork entities guide or route the data unit to its intendeddestination, i.e. the receiver. This will briefly be explained withreference to FIG. 1. FIG. 1 shows a communications network 2 andcommunication devices 10-14, which are capable of accessing network 2.Network 2 is shown as comprising a plurality of forwarding entities21-25. It is noted that the representation in FIG. 1 is only schematicand that real networks generally comprise a far larger amount offorwarding entities and accessing entities. It is noted that within thecontext of the present specification and claims, any functional elementcapable of interacting with or interacting in a communication networkwill be referred to as a network entity. Moreover, it may be noted thatthe term entity refers to any element capable of providing a certainfunction (such functions e.g. being sending and/or forwarding and/orreceiving), where an entity can be provided by hardware, software or anysuitable combination of hardware and software, and an entity can beprovided by one physical unit (such as a computer, server, telephoneterminal, etc.) or can be spread over several physical units.

In the schematic example of FIG. 1, if e.g. network entity 10 sends datato network entity 11, it will divide the data to be sent into segments,place the segments into data units, where each data unit has a structuredefined by the communication protocol governing the communication overnetwork 2. A communication protocol is a set of rules for arranging dataand for handling data in entities operating in accordance with theprotocol. Examples of such communication protocols are TCP (TransmissionControl Protocol), XCP (explicit Control Protocol) or various versionsof ATM (Asynchronous Transmission Mode) protocols.

FIG. 3 shows a schematic example of a data unit 21. In this example, thedata unit has a beginning identifier 31, an ending identifier 32, aheader 33 and a payload section 34. The data segment to be sent to thereceiver is placed in the payload section 34, whereas informationrelated to the forwarding and handling of data unit 21 is set in theheader 33 in accordance with the rules laid out by the protocolgoverning the transmission. For example, the protocol can prescribe thata specific field 331 is a forwarding data field containing informationthat is used by forwarding network entities for forwarding the data unit21 to the designated receiving network entity. Such information can e.g.be an address within an addressing scheme provided by the protocol. Itis noted that the term field within the present specification and claimsrelates to any identifiable section of a data unit, where such a sectionmay consist of a contiguous number of data symbols (e.g. bits), or canbe spread out over the data unit. Furthermore, it is noted that variousprotocols use different names for their basic data units, such asprotocol data unit, frame, packet, etc., and that the term data unit isused generically in the present specification and claims to relate toany such subdivision of data being sent in accordance with a givenprotocol.

Consequently, if sending network entity 10 would like to transmit datato receiving network entity 11, it divides the data into segments andplaces these segments into data units 21, in which appropriateinformation leading towards network entity 11 is set in field 331. Thesedata units 21 are then passed into the network, e.g. forwarding networkentity 21 as shown in FIG. 1. Forwarding network entity 21 then handlesand forwards the data units in accordance with the rules given by theunderlying protocol, such that these data units pass to receivingnetwork entity 11 via further forwarding entities 22, 23, 24 or 25, 24.This concept is well known in the art and therefore does not need to bedescribed in further detail here.

PROBLEM UNDERLYING THE INVENTION

As can be seen in the schematic example of FIG. 1, a data unit orientedcommunication system will generally contain a large number of forwardingnetwork entities (such as the entities 21-25 shown in FIG. 1), whereeach of these forwarding entities handles data units arriving from anumber of other network entities, such as the shown accessing entities10-14, but possibly also from other forwarding network entities withinthe network. A set of data units that have a sending network entity anda receiving network entity in common are sometimes also referred to as aflow. Therefore, expressed in other words, each forwarding networkentity in network 2 will typically simultaneously handle a plurality offlows. It is easily understandable that this provides for complicatedcontrol situations within each individual network and within the networkas a whole.

OBJECT OF THE INVENTION

The object of the invention is to provide a mechanism for improving thecontrol possibilities and options in networks and communications of theabove-described type.

SUMMARY OF THE INVENTION

This object is solved by the subject-matter of the independent claims.Advantageous embodiments are described in the dependent claims.

In accordance with the present invention a first data field is providedin a data unit being transmitted, which field is arranged to containnetwork entity identification information, in order to identify anetwork entity involved in the communication from the sending networkentity to the receiving network entity. This includes the possibleidentification of the sending entity or the receiving entity.Furthermore, this specific data field is different from the abovementioned forwarding data field designated by the underlyingcommunication protocol to contain information to be used by forwardingnetwork entities for forwarding the data unit to the receiving networkentity. The additional data field of the invention is defined in such away that a given network entity that reads this data field can at leastmake a decision on the basis thereof whether this given network entityis identified or not.

Consequently, an important concept of the present invention consists inproviding an identification mechanism in each data unit, such thatwithin a given end-to-end communication or flow, an addressing ofnetwork entities involved in this communication can be performed. Animportant advantage is that the plurality of network entities involvedin the communication do not have to store any flow related informationon the potentially very large number of flows passing through, as theyonly need to embody a mechanism for identifying themselves, i.e.determining whether a given data unit identifies the network entity thatis processing that data unit, or not. Consequently, the increase incomplexity is very low, but due to the identification mechanism a newdegree of freedom is gained for performing control operations within adata unit oriented communication system.

For example, it is possible to convey specific information to a givennetwork entity that is involved in a end-to-end communication between asending network entity and receiving network entity.

According to a preferred embodiment of the present invention, the abovedescribed general concept is applied in the context of a distributedcongestion control mechanism, in which multiple network entities cangive congestion control information to the communicating end-points.

BRIEF DESCRIPTION OF FIGURES

In the following, the concepts and advantages of the present inventionwill be described by referring to preferred embodiments, which aredescribed in conjunction with the appended figures, in which

FIG. 1 is a schematic representation of a communication network andassociated network entities;

FIG. 2 a shows a schematic block diagram of a sending network entity;

FIG. 2 b shows a schematic block diagram of a forwarding network entity

FIG. 2 c shows a schematic block diagram of a receiving network entity;

FIG. 3 is a schematic representation of a data unit;

FIG. 4 is a basic flow chart describing one method embodiment of thepresent invention;

FIG. 5 is a flow chart showing an example of a procedure shown in FIG.4;

FIG. 6 is a flow chart of a preferred method embodiment of the presentinvention as applied in a forwarding network entity; and

FIG. 7 is a flow chart of a method embodiment as implemented in areceiving network entity.

DETAILED DESCRIPTION OF EMBODIMENTS

Although the following description of preferred embodiments of theinvention will sometimes make reference to specific communicationprotocols, it is noted that the present invention can be applied to anycommunication protocol that falls into the general context of one of theindependent claims. In other words, the present invention is notrestricted to any specific protocol or protocols.

The present invention can be applied to a communication system aspreviously described in FIG. 1 and to data units 21 as previouslydescribed with respect to FIG. 3. Namely, in accordance with theinvention, a specific data field is added to a data unit beingtransmitted. As already described previously with respect to FIG. 3, thedata unit 21 has a forwarding data field 331 designated by thecommunication protocol to contain information to be used by forwardingnetwork entities for forwarding the data unit to the intended receivingnetwork entity. In accordance with the invention, a new data field isprovided in the data unit, said new data field being referred to as 332in FIG. 3. The new field 332 is arranged to contain network entityidentification information. The new field 332 and the information to becontained therein is defined in such a way that a given network entitythat reads the field 332 can at least make a decision on the basisthereof whether the given network entity is identified or not. Inaccordance with a method of controlling the overall transmission fromthe sending network entity to the receiving entity, the one or moreforwarding network entities involved in the transmission perform a dataunit processing operation after receiving a given data unit, whichcomprises reading the new data field 332 and making an identificationdecision on the basis thereof, whether the forwarding network entitypresently handling the received data unit is identified therein or not.

There are various possibilities for specifically using theabove-described general concept. For example, the provision of the newnetwork entity identification field 332 can be used to conveyinformation to a given forwarding network entity. In other words, e.g.the sending network entity is thereby made capable of communicating withindividual selected forwarding network entities that are involved inforwarding data units between the sending and the receiving networkentity. This can be used to convey specific information to a forwardingnetwork entity thus defined, in which case the data unit processingoperation in the forwarding network entities comprises reading includedinformation in the data unit, if the identification decision determinesthat the forwarding network entity performing the data unit processingoperation is identified in the new field 332.

According to another aspect of the invention it is possible to definethat the network entity defined in the new field 332 is associated withthe fulfilment of a predetermined condition with respect to the othernetwork entities involved in the transmission from the sending networkto the receiving network entity. In other words, the control procedurein the forwarding network entities and the receiving network entitiescan use the identification information contained in the new field 332for internal control purposes, as the system is arranged in such a waythat the network entity identified in the new field plays a specificrole within the context of the overall communication from the sending tothe receiving network entity. For example, the network entity identifiedin the new field can be associated with providing the smallest amount oftransmission capacity to the transmission between the sending networkentity and the receiving entity among all network entities involved inthe transmission, i.e. the new field 332 can be defined to identify thebottleneck of the transmission.

Preferably, if the network entity identified in the new field isassociated with a specific condition, the data unit processing operationin the forwarding network entities furthermore comprises a decisionprocedure for deciding whether to change the contents of the new field,and a changing procedure for changing the contents of the new field independence on the outcome of the decision procedure. The decisionprocedure can be linked to testing the specific condition in thepresently acting forwarding network entity. For example, each forwardingnetwork entity that receives a data unit can determine whether itfulfils the condition associated with the network entity identified inthe new field 332, and then enter its own identification if thecondition is fulfilled, to thereby notify the subsequent networkentities of this fact.

The addition of the new data field 332 to data units can be accomplishedin any suitable or desired way. For example, it is possible to modifygiven communication protocols by additionally defining a field of theabove-described type at an appropriate location in data units of saidmodified communication protocol. However, it may be noted that it is notnecessary to redefine protocols in order to implement the concept of thepresent invention, because it is equally possible to adapt networkentities using the present application to make use of such portions of adata unit that are left unassigned by the underlying communicationprotocol. If the latter implementation is chosen, then only such networkentities adapted to the invention will look into the proper portion of adata unit, whereas compatibility to non-adapted network entities isretained, because these do not use the newly defined field. However, itis preferable to indeed adapt a given communication protocol to definethe new data field 332 as indicated above, such that all networkentities operating in accordance with the protocol can use the conceptsof the present invention. In this way, the present invention can beembodied in the form of a communication protocol, where the rules of theprotocol provide for the new network entity identification field 332 asdescribed above. Equally, the present invention can be embodied in theform of a data unit carrying such a new network entity identificationdata field 332.

The locating of the new data field 332 within a data unit can beaccomplished in any suitable or desirable way, e.g. as known for fieldsalready in use. For example, a given position in the data unit can beidentified by using the first data symbol (e.g. bit or byte) followingthe start mark 31 as the origin, and then defining the field with twocoordinates counted from said point of origin, said two coordinatesdefining the beginning and end of the field. Namely, the field 332 cane.g. be defined as all data symbols found between the locations n andn+k, n and k being positive integers that describe the umber of symbolscounted from the point of origin. However it should be noted that thisis only an example, and it is e.g. also possible to spread the contentsof the field 332 over the data unit in a non-contiguous manner.

Preferably, the new data field 332 is not only able to identify a givennetwork entity, but much rather defined such that a given network entitythat reads the network entity identification information from the fieldcan make a decision on the basis thereof whether no network entity atall is identified by said new data field 332. This feature can beprovided in any desirable or suitable way, e.g. by defining that allvalues falling within a certain category (e.g. all negative values) areto be associated with the information that no network entity isidentified. Preferably, the information that no network entity at all isidentified is associated with a predetermined default value for the newdata field 332, e.g. a predetermined symbol sequence, such as −1.

The specific way of defining the information structure in the new datafield 332 can be done in any suitable or desirable way. For example, itis possible to let the network entity identification information in thenew field 332 comprise a unique identifier, where each network entityinvolved in the communication has assigned its own identifier, such thatthe identification decision comprises comparing the unique identifiercontained in the new data field 332 with the unique identifier assignedto the forwarding network entity performing the data unit processingoperation.

Another way of arranging the information in the network entityidentification field 332 is if the data units being sent comprise someform of count value, where this count value is set to a predeterminedinitial value in the sending network entity and where each forwardingnetwork entity changes (e.g. increments or decrements) the count valueby a predetermined count difference value (e.g. 1) after receiving adata unit. The changed count value is then set into the data unit beforeforwarding it. An example of such a count value is the so-calledtime-to-live (TTL) parameter known from IP (Internet Protocol). The TTLparameter is chosen to an initial value of 64 and decremented each timethat the data unit is forwarded. If the TTL value reaches zero, the dataunit is dropped. The purpose of the TTL value is to avoid excessiveforwarding within the network, especially in the context of a back andforth reflection between two entities.

If a count value of the above-mentioned type is employed for the dataunits being forwarded, then the network entity identificationinformation in the new data field 332 may be selected to have the sameformat as the count value, namely in the form of a count compare value.The identification decision then comprises comparing the count comparevalue from the field 332 with the count value read from the receiveddata unit and/or with the changed count value set in the data unitbefore forwarding.

Using the down-counter like TTL as example, the identification conceptcan e.g. be used in the following way. The sending network entity sets apredetermined initial value, e.g. 64 in an appropriate location within adata unit being sent, e.g. the field 333 shown in FIG. 3. Furthermore,if the sending network entity wishes to identify a network entity in thenetwork entity identification field 332, it sets a number in the rangeof 0-64 in this field, e.g. 62. If the forwarding network entities arethen arranged to compare the decremented value of counter field 333 withthe value in field 332, then the value 62 identifies the secondforwarding network entity along the path from the sending network entityto the receiving network entity.

Although the above example used a counter that is decremented, it isequally well possible to use a counter that is incremented. In this casethe initial value could e.g. be 0, and a value of n (n being a positiveinteger) in the network entity identification field 332 then identifiesthe n-th network entity along the path from the sending network entityto the receiving network entity.

It is noted that one of the advantages of using the counter basedidentification system is that the network entities themselves do notneed to store any information on their own identification. Namely, theidentification is a relative form of identification, which is derivedfrom each individual data unit.

In connection with the concept of relative identification, it is notedthat it is furthermore possible to implement the data unit processingoperation in the forwarding network entities (and in the receivingnetwork entity) in such a way, that a procedure is provided for furtherdistinguishing whether a received data unit has passed the networkentity identified in the network entity identification field 332 or not.In the context of using a counter value of the basis for identification,this can be done by comparing whether the count compare value in thatidentification field 332 is larger or smaller than the count value inthe counter field 333.

However, the concept of determining whether a received data unit haspassed the network entity identified in the network entityidentification field 332 or not, can also be implemented within thecontext of any arbitrary identification scheme. Namely, it is in anycase possible to add to the data units a further date field, e.g.identified as 334 in FIG. 3, which provides information on whether thenetwork entity identified in field 332 has been passed or not. Thisfield 334 is independent of the field 332, and can e.g. consist of asingle bit, where one bit value indicates that the identified networkentity has been passed and the complementary value indicates that theidentified network entity has not been passed. It is noted that the useof the additional field 334 for identifying whether the entity in field332 has been passed or not, is not necessary within the context of asystem using a counter value in field 333, but it is none the lesspossible to also implement field 334 in addition to field 333.

A generalized example of the above described inventive concept is shownin FIG. 4. FIG. 4 shows a flow chart of a general control methodemployed in a forwarding network entity or in a receiving networkentity. After a data unit has arrived in step S41, a data unitprocessing operation is commenced. A data unit processing operation isindicated by the dash-line box. In a first step S42, the network entityidentification (NEid) data field 332 is read. Then, in step S43 it isdetermined whether the network entity presently handling the data unitis identified in the NEid data field. This can be accomplished inaccordance with one of the above mentioned identification concepts.Then, if the presently acting network entity is not identified, a firstprocedure is conducted in step S44, and if the acting entity isidentified, a second procedure S45 is enabled. No details of theprocedure in S44 or S45 is shown, as this will depend on the specificrequirements and desires. If the network entity performing the methodshown in FIG. 4 is a forwarding network entity, then the data unitprocessing operation finally passes to a step S46 of outputting a dataunit.

One or more of the above described additional, preferred concepts can beimplemented in the data unit processing operation. This is shown in theexample of FIG. 5. Steps S42 and S43 are as described in connection withFIG. 4, such that a repeated description is not necessary. The use of amechanism for determining whether no network entity at all is identifiedin the NEid data field 332 can e.g. be employed in a decision step S51that follows decision step S43 if the outcome of S43 indicates that anetwork entity presently handling the data unit is not identified. Ifthe outcome of step S51 indicates that indeed a network entity isidentified (outcome “no” in FIG. 5) then procedure 1 is entered, asindicated by S44. Furthermore, in the example of FIG. 5, procedure S44has the additional determination step of deciding whether the data unithas passed the identified network entity or not, see S441. Subsequentthereto, appropriate steps can be taken as is desired or required withinthe given context, which is not shown, as it is of no further importancefor the present invention.

If the outcome of step S51 indicates that no network entity at all isidentified (e.g. because a predetermined default value is contained inthe NEid field 332) then a procedure S52 is enabled. This procedure S52can e.g. contain a decision step S521 to determine whether the NEid datafield 332 is to be changed or not. If it is decided to not change thefield, then the procedure continues without changing the field, andotherwise a step S522 is enabled, for changing the field in accordancewith a desired mechanism. For example, if the NEid data field is definedto indicate the bottleneck of the communication between the sendingnetwork entity and the receiving network entity, then step S521 may makethe decision to change or leave the NEid data field 332 depending onwhether another procedure (not shown in FIG. 5) has determined that thepresently acting network entity is the bottleneck, such that its NEidvalue should be set in the NEid data field 332.

Finally, in the example of FIG. 5, if the outcome of step S43 indicatesthat the presently acting network entity is indeed identified in theNEid data field 332, then procedure S45 is enabled (like in the exampleof FIG. 4), where in the example of FIG. 5 it is additionally indicatedthat procedure S45 comprises a step S451 of extracting information fromthe received data unit, said information being directed towards thenetwork entity identified in the NEid data field 332 and having beenplaced in the data unit by one of the preceding (upstream) networkentities.

There may be an arbitrary number of further steps prior to S441, S521and S451, and equally an arbitrary number of subsequent steps within thedata unit processing operation, which are not shown in the figure, asthey will depend on the specific desires and requirements involved inthe communication system to which the invention is applied, and are ofno importance for the present invention. The data unit processingoperation finally passes to step S46 for outputting the data unit, ifthe network entity processing the data unit is a forwarding data unit.

FIG. 7 shows a flow chart of a control method that can be implemented ina receiving network entity operating in accordance with the presentinvention. It is assumed that data units are arranged in such a way thatthe NEid data field not only allows deciding whether a network entityprocessing the data unit is identified or not, but also allows adecision whether no network entity at all is identified in the NEid datafield. Furthermore, it is assumed that a feedback mechanism isimplemented, according to which the receiving network entity sendsfeedback messages to the sending network entity after having receiveddata units, where a feedback message contains information related to thereceipt of a corresponding data unit. An example of such a mechanism isARQ (Automatic Repeat reQuest).

As can be seen in FIG. 7, after having received a data unit in step S71,some form of basic processing is performed in procedure S72, where saidbasic processing will depend on the given protocol and communicationenvironment, and is of no further importance to the present invention,such that no further details are shown. Then in step S72 the networkentity identification information NEid is extracted from thecorresponding field. In decision step S74 it is decided whether nonetwork entity is identified at all. If indeed no network entity isidentified at all, the procedure branches to step S77. In step S77, afeedback message sent in response to receiving the data unit that hasbeen processed is arranged such that an indication is set therein toinform the sending network entity that a receiving network entity hasidentified no network entity with respect to the NEid field. This cane.g. be accomplished by setting the same default value in a NEid fieldin the feedback message, e.g. an acknowledgement message.

If the outcome of step S74 indicates that a network entityidentification is contained in the corresponding field, then theprocedure can immediately go to a step S76, in which the received NEidis set in an appropriate field of the feedback message. Further, asshown in FIG. 7, it is also possible to add a further decision step, inwhich it is determined whether the received data unit has passed thenetwork entity identified in the network entity identification field. Ifit is determined that the data unit has not passed the network entityidentified in the NEid data field, then the procedure branches to stepS77 again, in which the appropriate field of the feedback message is setto indicate no identification of a network entity. Namely, if step S75determines that the identified network entity has not been passed, thenthis means that the path or route of the sequence of data units sentfrom the sending network entity to the receiving network entity haschanged with respect to paths followed by previous data units sent fromthe sending network entity to the receiving network entity. It may benoted that subsequent to such a determination in step S75, there canalso be the additional step of adding an explicit indication of thisfact to the feedback message.

On the other hand, if the outcome of step S75 indicates that the dataunit has passed the network entity identified in the NEid data field,then previously described step S76 is performed. Further, subsequent toadding appropriately set NEid information in the feedback message, thefeedback message is outputted in step S78.

Preferably, the sending network entity is arranged in such a way that issets the initial value in the network entity identification data fieldto a value derived from one or more of the feedback messages generatedin accordance with the procedure of FIG. 7.

Now a preferred embodiment of the invention will be described withreference to FIG. 6. FIG. 6 shows a flow chart of a specific data unitprocessing operation conducted in a forwarding network entity. Inaccordance with the embodiment of FIG. 6, the transmitted data unit 21(see FIG. 3) contains a predetermined data field that contains a desiredtransmission volume parameter (TVP). The desired transmission volumeparameter can e.g. be a data amount value (such as a window size in awindow-based flow control scheme), a data rate value (in a rate basedcontrol scheme), or any suitable combination of a data rate value anddata amount value.

The TVP data field, which is shown as 335 in FIG. 3, is set to a desiredvalue in the sending network entity. In other words, the sending networkentity places information into the sent data units, which informationindicates how much transmission value (e.g. in terms of data amount ordata rate) the sending network entity desires.

The data unit processing operation performed in the one or moreforwarding network entities between the sending network entity and thereceiving network entity, of which the method shown in FIG. 6 is anexample, comprises a procedure for determining a transmission volumeparameter available at the forwarding network entity performing the dataunit processing procedure, where said available transmission volumeparameter will be referred to as TVPav. The data unit processingoperation furthermore comprises comparing the available transmissionvolume parameter TVPav with the value contained in the TVP data field(which may be the initial desired value set by the sending entity, or avalue subsequently modified by one of the forwarding network entitiespreceding the present network entity). Furthermore, the data unitprocessing operation comprises deciding whether to set the availabletransmission volume parameter TVPav in said TVP data field, depending onthe outcome of whether the present network entity is identified in theNEid data field and the outcome of the step of comparing TVPav with TVPderived from the TVP field.

Preferably, the data unit processing operation comprises setting thevalue TVPav in the TVP data field if TVPav is smaller than the valuecontained in the TVP field of the received data unit, and otherwiseleaving the TVP field unchanged. In other words, if it is determinedthat the transmission volume parameter available at the present networkentity is smaller than the value desired by the sending network entityor the value reduced by a preceding forwarding network entity, then thisinformation should be provided to subsequent network entities.Therefore, the TVP data field is appropriately set to this (up to now)lowest available TVP.

Preferably, the possible modification of the NEid data field is done inthe following way:

If the outcome of the step for deciding whether the present networkentity is identified in the NEid data field indicates that the NEid datafield identifies the present network entity or identifies no networkentity at all, then the NEid data field is set to identify no networkentity at all in the forwarded data unit, if the available transmissionvolume parameter TVPav is larger than the value contained in the TVPdata field, and the NEid data field is set to identify the presentnetwork entity if the available transmission volume parameter TVPav issmaller than the value contained in the TVP data field.

On the other hand, if the outcome of the identification decisionindicates that the NEid data-field identifies a different network entitythan the present one, and if the available transmission volume parameterTVPav is smaller than the value contained in the TVP data field, aprocedure is performed for determining whether the data unit has passedthe network entity identified in the NEid field or not. If it isdetermined that the data unit has passed the network entity identifiedin the NEid data field, the NEid data field of the data unit to beforwarded is set to identify the present network entity, and if it isdetermined that the data unit has not passed the network entityidentified in the NEid data field, the NEid data field is leftunchanged.

An example of the above-described concepts is shown in FIG. 6. Afterhaving received a data unit, the values of the NEid data field and theTVP data field are extracted. Then, in step S62, the availabletransmission volume parameter TVPav is determined (examples thereof willbe given further on). Subsequent to step S62, a decision is made in stepS63, whether the NEid extracted from the received data unit identifiesthe present network entity (own id) or it identifies no network entityat all. If the outcome of step S43 indicates that NEid identifies thepresent network entity or no network entity at all, the procedure passesto step S64. Step S64 decides whether the transmission volume parameteravailable at the present network entity exceeds the transmission volumeparameter given in the received data unit. In other words, it is checkedwhether the present network entity provides the lowest transmissionvolume parameter for the data unit among the network entitiesencountered so far by the data unit. If the outcome of step S64 is thatthe available transmission volume parameter is larger than the oneindicated in the received data unit, which means that either the desiredTVP or the TVP available at a preceding network entity is smaller, thevalue of TVP in the TVP data field is left unchanged, and the value ofNEid in the NEid data field is in any case set to identify no networkentity at all.

On the other hand, if the outcome of step S64 indicates that thetransmission volume parameter available at the present network entity isindeed the smallest so far (outcome “no”), then the procedure branchesto step S67, where the available transmission volume parameter TVPav isset in the TVP data field of the data unit being forwarded and the valueof NEid identifying the present network entity is set in the NEid datafield. In other words, the present network entity still has the smallesttransmission volume parameter (if step S63 identified the NEid of thepresent network entity) or has become the network entity with the lowestavailable transmission volume parameter (if step S63 indicated that NEidin the received data unit identified no data unit at all).

On the other hand, if the outcome of step S63 indicates that a differentnetwork entity than the present network entity is identified in the NEiddata field (outcome “no”), the procedure branches to step S65. Step S65is identical to step S64 in that it determines whether the transmissionvolume parameter available at the present network entity is larger thanthe transmission volume parameter indicated in the TVP data field of thereceived data unit. If the outcome of step S65 is such that theavailable transmission volume parameter is larger than the one indicatedin the data unit, the NEid data field and the TVP data field are leftunchanged in the forwarded data unit. Further, if the outcome of stepS65 indicates that TVPav is smaller than TVP (outcome “no”), theprocedure branches to step S68.

Step S68 is a step for determining whether the network entity identifiedby the NEid in the NEid data field of the received data unit has beenpassed or not. If the outcome of step S68 indicates that the identifiednetwork has been passed, the procedure goes to step S69, in which theavailable transmission volume parameter TVPav is set in the TVP datafield of the data unit to be forwarded, and the identification of thepresent network entity is set in the NEid data field of said data unitto be forwarded. The id of the present network entity is set, becausethe branch leading to step S69 indicates that the network entityidentified in the NEid data field is located upstream of the presentnetwork identity such that the present network entity is the newbottleneck of the connection, which is appropriately to be registered inthe data unit being forwarded.

On the other hand, if the outcome of step S68 indicates that the networkentity identified in the NEid data field of the received data unit hasnot been passed, i.e. the bottleneck identified by the field is locateddownstream, then the procedure passes to step S70 in which thetransmission volume parameter available at the present network entity isset into the TVP data field in the data unit being forwarded, but theNEid field is not changed. If the present forwarding network entity isstill the bottleneck for a subsequent data unit sent from the sendingnetwork entity to the receiving network entity (i.e. for a subsequentdata unit of the flow after one RTT, such that the receiving networkentity could feed back the value in the NEid field to the sendingnetwork entity, and the sending network places this identifier in saidsubsequent data unit), then it will get its identifier written into theNEid field (in step S67).

The method described in connection with FIG. 6, which is implemented ina forwarding network entity, is preferably, combined with the method fora receiving network entity described in connection with FIG. 7, with thefollowing addition. The value contained in the TVP data field of thedata unit received at the receiving network entity is in any case copiedinto the feedback message sent to the sending network entity. Thereby,the sending network entity is informed of the available transmissionvolume parameter, and can accordingly adjust its control procedure foroutputting further data units to the same receiving network entity onthe basis of this information. Furthermore the receiving network entitywill inform the sending network entity either of the network entityhaving the lowest available transmission volume parameter (thebottleneck), see step S76 in FIG. 7, or will inform the sending networkentity that no network entity with a lowest transmission volumeparameter is known for the received data unit (i.e. no bottlenecknetwork entity is known). The sending network entity can thenappropriately add this NEid information received from the receivingnetwork entity into further data units sent to the same receivingnetwork entity.

In the above-described example of FIG. 6, a situation was considered inwhich no separate field 334 (see FIG. 3) is provided, i.e. a field thatidentifies whether the network entity identified in the NEid data fieldhas been passed or not by the data unit carrying said fields. Forexample, this can be the case if the above-described concept of using acounter and a counter compare value are used for identificationpurposes. However, if the additional field for indicating whether thenetwork entity identified by the NEid field has been passed or not isused, it is preferable to amend the procedure shown in FIG. 6 by settingthis additional field to the indication of “network identity has beenpassed” in steps S66 and S67, but to leave this field unchanged in stepsS69 and S70. It may be noted that when using this additional field, stepS68 can be implemented by simply checking the setting of this field.Namely, if the outcome of step S68 is “yes”, then the additional fieldis already set to indicate that the network entity identified in theNEid data field has been passed, and if the outcome of step S68 is “no”,then the field indicates that the network entity identified in the NEiddata field has not been passed, which should be kept that way at theoutcome of step S70. If the present forwarding network entity is stillthe bottleneck for a subsequent data unit sent from the sending networkentity to the receiving network entity (i.e. for a subsequent data unitof the flow after one RTT), then it will get its identifier written intothe NEid field (in step S67).

Regarding the step S62 of FIG. 6, in which the available transmissionvolume parameter TVPav is determined, this value can be determined inany suitable or desirable way. For example, it can be accomplished bydetermining the difference between the output data rate or capacityavailable at the output link of the present forwarding network entityand the rate of incoming data units. In other words, this corresponds tothe overall bandwidth difference between outgoing data units andincoming data units. This value can suitably be processed to obtain anoverall available transmission volume parameter, i.e. the transmissionvolume parameter available to the sum of all incoming data units. If thetransmission volume parameter is a rate, when the difference between theoutput rate and input rate can simply be directly taken as the overallavailable transmission volume parameter, or possibly multiplied by adimensionless coefficient. If the transmission volume parameter is adata amount, then the difference between the output rate and the inputrate must be appropriately processed by a coefficient to produce a dataamount value.

In the simplest case, this overall available transmission volumeparameter can then simply be divided onto all incoming data units bysimply dividing the overall available transmission volume parameter bythe number of presently incoming data units. However, in accordance withthe present invention, it is preferred to calculate the availabletransmission volume parameter for individual data units bydistinguishing such incoming data units that identify the presentnetwork entity in their NEid data field or identify no network entity atall in their NEid data field from those which identify a differentnetwork identity in said field. In other words, it is preferable todivide the available transmission volume parameter onto incoming dataunits taking into account whether these incoming data units identify thepresent network entity as their bottleneck or not. Then the availabletransmission volume parameter for a given data unit is calculated independence on the overall available transmission volume parameter, oneor more data unit related parameters (such as the size of the data unit,the roundtrip time identified in the data unit, etc.) and anormalisation sum, where the normalisation sum runs over a predeterminedset of data units being forwarded (i.e. incoming data units), saidpredetermined set comprising only those data units that either identifythe present forwarding network entity or identify none at all in theirNEid data field. In this way, the normalisation sum only takes intoaccount contributions from incoming data units (more specifically: fromdata units arrived within a predetermined control interval) that do notidentify in their NEid data field a bottleneck in another networkentity. As a consequence, the available overall transmission volumeparameter is not falsely divided with respect to such data units thathave their bottleneck elsewhere. Only those data units are taken intoaccount for which the present network entity is indeed the bottleneck.

Now a specific application of the concept described in connection withFIG. 6 to a specific problem will be explained. This explanation willmake reference to a communication protocol referred to as XCP (explicitControl Protocol), which is a preferred application. However, it mayalready be noted that the concept of FIG. 6 can also be applied to otherprotocols having similar properties as XCP. XCP has been proposed as analternative transport protocol to TCP (Transport Control Protocol), seee.g. the paper “Congestion Control for High Bandwidth-Delay ProductNetworks” by Dina Katabi, Mark Handley and Charlie Rohrs, SIGCOMM′ 02,Aug. 19-23, 2002. XCP is considered to be very useful in mobileenvironments with time varying end-to-end path properties owing to usermobility, radio channel fluctuation and radio capacity limitation. Inthese cases XCP can achieve faster conversions towards a change in linkproperties compared to TCP, achieve a better link utilisation, which isin particular important for expensive radio spectrum, and work withlargely reduced number of packet losses, which is beneficial for anyapplication sending data.

In accordance with XCP, a window-based flow control is used in the dataunit sender. The header of a XCP data unit comprises a field in whichthe momentary congestion window of the sender is written, said fieldbeing called H_cwnd. Furthermore, a field is provided in which thesender writes its current RTT estimate, said field being called H_rtt.Finally, XCP also provides for a field H_feedback, which is modified byforwarding network entities between the sender and receiver, in order toinfluence the congestion windows at the source. In other words, thefield H_feedback, which contains a data amount, contains a transmissionvolume parameter in the above-described sense. Each forwarding networkentity operating in accordance with XCP determines the value ofH_feedback available to an individual data unit, and if this value issmaller (the field can take negative values) than the value contained inthe received data unit, then the new smaller value is written into theforwarded data unit. In this way, the receiving network entity acquiresinformation on the most limiting entity (i.e. the bottleneck) along theconnection between the sender and the receiver, and the receivingnetwork entity places this information into a feedback message sent tothe sending network entity.

Consequently, the sending network entity can adjust its data unit flowcontrol.

However, there is a fundamental problem with the algorithms used in XCP.The operation of the forwarding XCP network entities is that if theforwarding network entity experiences congestion (the overall incomingtraffic grows beyond the outgoing capacity), this network entity istreated as being the bottleneck for all of the flows passing throughthis specific network entity. However, this assumption is not in generalvalid. In particular, in mobile environments many flows sharing the samenetwork path can greatly differ in the path capacity, due to thecapacity in the last (e.g. wireless) link. As a consequence, thebandwidth allocation algorithms in a forwarding XCP network entity cancause an under-utilisation of links. This can be explained byconsidering an example in the context of FIG. 1.

Namely, if one considers two flows, one from network entity 13 tonetwork entity 10 via forwarding network entity 25 and 21, and one fromnetwork entity 13 to network entity 12, via forwarding network entities25, 21, 22. If one assumes that the connection between 22 and 12 is alow bandwidth connection, e.g. a mobile link having an availablebandwidth of 64 kbps, whereas the connection between 21 and 10 is a highbit rate connection, e.g. a fixed line access link having 2 Mbps, thefollowing situation can occur in XCP. Network entity 25 can becomeoverloaded in the sense that the amount of incoming traffic exceeds theoutput capacity. The algorithm used by XCP for dividing the availablebandwidth over the incoming data units will give the same fair share toall data units. However, it is well possible that although entity 25 isthe bottleneck for the connection between 13 and 10, it is not thebottleneck for the connection between 13 and 12. If one e.g. assumes anavailable bandwidth of 1 Mbps between network entities 25 and 21, thismeans that each of the two flows receives 0.5 Mbps. However, the flowdirected towards network entity 12 can only utilize 0.64 Mbps, such thatin total only 0.564 Mbps of the available 1 Mbps will be utilized in thelink between network entities 25 and 21. Therefore, there is a linkunder-utilization problem in XCP.

As indicated further above, the present invention can solve thisproblem, as each network entity can distinguish whether it is in factthe bottleneck for a given data unit or not. By only taking into accountthose data units for which it actually is the bottleneck, or for whichno bottleneck at all is identified, a forwarding network entity usingthe previously described concepts can avoid assigning bandwidth (moregenerally an available transmission volume parameter) to data units thatbelong to a flow that is limited in another network entity, i.e. has itsbottleneck elsewhere.

Within the context of a window-based flow control system as used by XCP,a number of examples for specifically calculating the availabletransmission volume parameter will be given.

In the context of XCP, the transmission volume parameter is calledH_feedback. The available transmission volume parameter will be referredto as feedback_new.

As a first step, the overall or aggregate feedback Φ given by aforwarding network entity in a control interval d is defined as:Φ=α·d·S−βQwhere the control interval d is the average RTT of all flows goingthrough the forwarding network entity, S is the so-called sparebandwidth available at the outgoing link (i.e. link capacity minus inputrate of incoming data units), Q is the queue size seen over a certaintime interval, and α and β are constant parameters.

In order to allow some “bandwidth shuffling” it is possible to add someshuffled bandwidth h in the bandwidth allocation algorithm (which allowssome faster convergence in the case of a small Φ):h=max(0,γ·y−|Φ|)where y is the average input traffic in an average RTT, and γ is aconstant.

The feedback_new value of a data unit i, referred to as feedback_new_(i)is calculated as:feedback_new_(i) =p _(i) −n _(i),where pi is the positive feedback of data unit i (in case of Φ>0) andn_(i) is the negative feedback (in case of Φ<0). If Φ<0, the forwardingnetwork entity could allocate extra bandwidth to its flows, whereas ifΦ<0, the forwarding network entity should reduce the current load.

For positive bandwidth allocation (Φ>0) p_(i) is defined as$p_{i} = {\xi_{p}\quad\frac{{rtt}_{i}^{2} \cdot s_{i}}{{cwnd}_{i}}}$where rtt_(i) is the RTT field in the congestion header of data unit i(the congestion header is a subunit of the full header), s_(i) is thesize of the data unit i, cwnd_(i) is the congestion window field in thecongestion header of data unit i, and ξ_(p) is a parameter which isdetermined as:$\xi_{p} = \frac{h + {\max\left( {\Phi,0} \right)}}{d \cdot {\sum\limits_{L^{\prime}}\frac{{rtt}_{i} \cdot s_{i}}{{cwnd}_{i}}}}$where the sum in the nominator is a normalisation sum running over a setof data units L′. The set of data units L′ contains every data unitarriving within the control interval d for which the identifier NEid inthe NEid data field (i.e. the bottleneck identifier) either identifiesthe present forwarding network entity or no network entity at all.

For negative bandwidth allocation (Φ<0) various allocation strategiescan be performed, depending on the fairness strategy that it is desiredto deploy. In the following, two examples will be given for suchfairness strategies, namely “max-min fairness” and “proportionalfairness”.

In the case of proportional fairness, the negative feedback per dataunit n_(i) is defined asn _(i)=ξ_(n) ·rtt _(i) ·s _(i)  (1)where rtt_(i) is the RTT field in the congestion header of data unit i,s_(i) is the size of data unit i and ξ_(n) is a parameter which isdetermined as$\xi_{n} = \frac{h + {\max\left( {{- \Phi},0} \right)}}{d \cdot {\sum\limits_{L}s_{i}}}$and the normalisation sum runs over a set of data units L. The set ofdata units L contains every data unit arriving within the controlinterval d, independent of the value contained in the NEid data field.

When using the “max-min” fairness strategy, n_(i) is defined like inabove-equation 3, but the parameter ξ_(n) is defined as$\xi_{n} = \frac{h + {\max\left( {{- \Phi},0} \right)}}{d \cdot {\sum\limits_{L^{\prime}}s_{i}}}$and the normalisation sum runs over the set of data units L′. The set ofdata units L′ contains every data unit arriving within the controlinterval d for which the network entity identification data fieldidentifies either the present network entity or no network entity atall. In other words, only those data units are taken into account, whichdo not identify a bottleneck elsewhere.

The forwarding network entity calculates an average rate r for all flowswhich do not have their bottleneck in some other network entity. Thisaverage rate r is obtained by averaging over the sending rate from allthe data units of the set L′. The sending rate of a flow is derived fromthe fields in the congestion header:r _(i) =cwnd _(i) /rtt _(i).

In addition, the number of flows N which do not have a bottleneck inanother network entity can be estimated as:$N = {\sum\limits_{L^{\prime}}\frac{1}{\frac{{cwnd}_{i}}{s_{i}} \cdot \frac{d}{{rtt}_{i}}}}$and the summing is done over the set of data units L′.

For all data units arriving at the forwarding data unit during a controlinterval when Φ<0, the following calculation of n_(i) may be performed,expressed in pseudo-code as: if (r+Φ/(d*N))<(cwnd_(i)/rtt_(i))||(NEid ==OwnID){ set n_(i) according to equation (1) } else { set n_(i)=0 // Thisflow is not required to reduce its rate, // but it is also not allowedto increase its rate // further. }

The above operation reduces the sending rates of data units that eitherwere already limited by the present forwarding network entity or wouldhave a higher than fair share after decreasing the load. Other flowsthat are not limited by the present network entity and do not exceedtheir fair share are left without reduction, but are also not allowed toincrease the rate (this is ensured by setting n_(i)=0).

Beyond the above described methods, which can be implemented in asending network entity and/or a forwarding network entity and/or areceiving network entity, the present invention also relates toappropriately arranged network entities themselves. This shall beexplained with reference to FIGS. 2 a, 2 b and 2 c.

FIG. 2 a shows a schematic block diagram of a sending network entity 10.As can be seen, the sending network entity 10 comprises a processor 101arranged to control the operation of the entity. Furthermore a datainput buffer 102 for receiving input data 20 as provided, connected to adata processing buffer 103 and an output buffer 104. Data units 21generated in the data unit processing buffer 103 under control ofprocessor 101 are output from output buffer 104. Furthermore, a memory105 is shown, which comprises programs, routines and procedures to beexecuted by processor 101, and may also serve to store values calculatedby processor 101. It may be noted that the buffers 102 to 104 and thememory 105 can be provided by a single memory arrangement that isappropriately accessed and manipulated by processor 101. The processor101 and memory 105 are arranged to execute the above described methodsfor the sending network entity, where the method may be implemented inthe form of software executed by processor 101. Therefore, the presentinvention can also be embodied as a computer program or a computerprogram product, and as a data carrier carrying such a computer programor computer program product.

In FIG. 2 a the generated data units 21 are output over a suitable ordesirable link (not shown in the figure), e.g. a fixed communicationline or a wireless communication link.

FIG. 2 b shows a schematic block diagram of a forwarding network entity.The structure is very similar to that of the sending network entity 10.Namely, the forwarding network entity 21 shown in FIG. 2 b has an inputbuffer 211, a processing buffer 212 and an output buffer 213. Thebuffers operate under the control of a processor 214, which in turn isconnected to a memory 215 for storing programs, routines and proceduresto be executed by the processor 214, as well as for storing valuescalculated by the processor 214. The forwarding network entity 21receives data units 21 over an appropriate link (not shown) and outputsdata units 211, which may be identical to the received data units 21, ormay have one or more fields changed by the forwarding network entity 21,in accordance with one of the above described control methods forforwarding network entities. As for the sending network entity 10 shownin FIG. 2 a, the control methods can be implemented in the form ofsoftware, such that the present invention can also be embodied as acomputer program or computer program product in the forwarding networkentity, or as a data carrier for such a computer program or computerprogram product.

Finally, FIG. 2 c shows a schematic block diagram of a receiving networkentity. The receiving network entity receives data units 21 or 21′ overan appropriate link (not shown) at an input buffer 112. Furthermore, aprocessing buffer 113 and an output buffer 114 are provided, from whichdata 23 is output in a suitable or desirable format. The buffers operateunder the control of a processor 111, which is connected to a memory 114that stores programs, routines and procedures be executed by processor111, and stores values calculated by processor 111. Furthermore, thereceiving network entity 11 shown in FIG. 2 c comprises a messagegenerator 116 for generating feedback messages 22 to be sent to thesending network entities belonging to individual received data units 21,21′.

The processor 111 and memory 115 are arranged to execute the abovedescribed control methods for the receiving network entity. In this way,the control method can be implemented in the form of software.Therefore, the present invention can also be embodied as a computerprogram or computer program product in the receiving network entity, andas a data carrier for such a computer program or computer programproduct.

It may be noted that although FIGS. 2 a to 2 c show a sending networkentity, a forwarding network entity and a receiving network entity,respectively, it is possible to combine all of the above describedelements into one device that is capable of being operated as one ormore of a sending, forwarding and receiving entity.

Although the present invention has been described on the basis ofdetailed embodiments, the scope of the invention is defined by theappended claims. Reference numerals in the claims are intended to makethe claims easier to understand, but are not limiting.

1. A method of controlling a transmission of data units arranged inaccordance with a predetermined communication protocol over a pluralityof network entities, said network entities operating according to saidpredetermined communication protocol, from a sending network entity to areceiving network entity over one or more forwarding network entities,comprising: providing in a data unit a first data field arranged tocontain network entity identification information (NEid), said firstdata field being different from a forwarding data field designated bysaid communication protocol to contain information to be used byforwarding network entities for forwarding said data unit to thereceiving network entity, said first data field being defined such thata given network entity that reads the first data field can at least makea decision on the basis thereof whether said given network entity isidentified or not, and in said one or more forwarding network entities,performing a data unit processing operation after receiving said dataunit, which comprises reading said first data field and making anidentification decision on the basis thereof whether the forwardingnetwork entity performing said data unit processing operation isidentified or not.
 2. The method according to claim 1, wherein saidfirst data field is further defined such that a given network entitythat reads the network entity identification information can make adecision on the basis thereof whether no network entity at all isidentified by said first data field, and said data unit processingoperation comprises, at least if the forwarding network entityperforming a data unit processing operation is not identified in thefirst data field, making a decision whether no network entity at all isidentified by said first data field.
 3. The method according to claim 2,wherein said first data field is defined such that if no network entityat all is identified, said first data field is set to a predeterminedfirst data field default value.
 4. The method according to claim 1,comprising including in said data unit information directed towards anetwork entity identified in said first data field, and where said dataunit processing operation comprises reading said included information ifsaid identification decision determines that the forwarding networkentity performing said data unit processing operation is identified insaid first data field.
 5. The method according to claim 1, wherein saiddata unit processing operation comprises a decision procedure fordeciding whether to change the contents of said first data field, and achanging procedure for changing the contents of said first data field independence on said decision procedure.
 6. The method according to claim1, wherein a network entity identified in said first data field isassociated with the fulfillment of a predetermined condition withrespect to other network entities involved in the transmission of dataunits from the sending network entity to the receiving network entity.7. The method according to claim 6, wherein said predetermined conditionis the providing of the smallest amount of transmission capacity to saidtransmission between said sending network entity and said receivingentity, among the network entities involved in the transmission of dataunits from the sending network entity to the receiving network entity.8. The method according to claim 1, further comprising: providing insaid data unit a second data field arranged to provide information onwhether a network entity identified in said first data field has beenpassed or not by said data unit, said second data field beingindependent of said first field.
 9. The method according to claim 1,wherein said network entity identification information comprises aunique identifier, each network entity being assigned its ownidentifier, and said identification decision comprises comparing theunique identifier contained in said first data field with the uniqueidentifier assigned to the forwarding network entity performing saiddata unit processing operation.
 10. The method according to claim 1,wherein said data unit comprises a count value, said count value beingset to a predetermined initial value in said sending network entity, andafter receiving said data unit in said one or more forwarding networkentities, said count value being changed by a predetermined countdifference value to a changed count value, and said changed count valuebeing set in said data unit before forwarding said data unit, where saidnetwork entity identification information comprises a count comparevalue of a same format as said count value, and said identificationdecision comprises comparing said count compare value with said countvalue and/or said changed count value.
 11. The method according to claim10, wherein said data unit processing operation comprises a procedurefor distinguishing whether said data unit has passed the network entityidentified in said first data field by determining whether said countcompare value is larger or smaller than said count value.
 12. The methodaccording to claim 1, comprising: providing in said data unit a thirddata field arranged to contain a desired transmission volume parameter,in said sending network entity, setting a desired transmission volumeparameter in said third data field of said data unit, and said data unitprocessing operation in said one or more forwarding network entitiescomprising: performing a procedure for determining a transmission volumeparameter available at the forwarding network entity performing saiddata unit processing procedure, comparing said available transmissionvolume parameter with the value contained in said third data field, anddeciding whether to set said available transmission volume parameter insaid third data field in dependence on the outcome of saididentification decision and the outcome of said step of comparing saidavailable transmission volume parameter with the value contained in saidthird data field.
 13. The method according to claim 12, wherein saidtransmission volume parameter is a data amount value or a data ratevalue.
 14. The method according to claim 12, wherein said data unitprocessing operation in said one or more forwarding network entitiescomprises: if said available transmission volume parameter is smallerthan the value contained in said third data field, setting saidavailable transmission volume parameter in said third data field beforeforwarding said data unit, and otherwise leaving said third data fieldunchanged.
 15. The method according to claim 3, wherein said data unitprocessing operation in said one or more forwarding network entitiescomprises: if the outcome of said identification decision indicates thatthe first data field identifies the forwarding network entity performingsaid data unit processing operation, or identifies no network entity atall, setting said first data field to identify no network entity at allif said available transmission volume parameter is larger than the valuecontained in said third data field, and setting said first data field toidentify the forwarding network entity performing said data unitprocessing operation if said available transmission volume parameter issmaller than the value contained in said third data field.
 16. Themethod according to claim 12, wherein said data unit processingoperation in said one or more forwarding network entities comprises: ifthe outcome of said identification decision indicates that the firstdata field identifies a network entity different from the network entityperforming said data unit processing operation, and if said availabletransmission volume parameter is smaller than the value contained insaid third data field, performing a procedure for determining whethersaid data unit has passed the network entity identified in said firstdata field or not, if it is determined that said data unit has passedthe network entity identified in said first data field, setting saidfirst data field to identify the forwarding network entity performingsaid data unit processing operation, and if it is determined that saiddata unit has not passed the network entity identified in said firstdata field, leaving said first data field unchanged.
 17. The methodaccording to claim 3, wherein said procedure for determining atransmission volume parameter available at the forwarding network entityperforming said data unit processing procedure comprises: determiningthe difference (S) between the output data rate available to saidforwarding network entity performing said data unit processing procedurefor forwarding data units and the rate of incoming data units,calculating an overall available transmission volume parameter on thebasis of said difference, calculating the available transmission volumeparameter for said data unit in dependence on said overall availabletransmission volume parameter, one or more data unit related parametersand a normalization sum, where said normalization sum runs over apredetermined set (L′) of data units being forwarded by said forwardingnetwork entity performing said data unit processing procedure, saidpredetermined set (L′) comprising only those data units that eitheridentify said forwarding network entity performing said data unitprocessing procedure in their first data field or identify no networkentity at all in their first data field.
 18. The method according toclaim 1, wherein said first data field is furthermore defined such thata given network entity that reads the network entity identificationinformation can make a decision on the basis thereof whether no networkentity at all is identified by said first data field, and said data unitprocessing operation comprises, at least if the forwarding networkentity performing a data unit processing operation is not identified inthe first data field, making a decision whether no network entity at allis identified by said first data field, in said one or more forwardingentities said data unit processing operation comprises a decisionprocedure for deciding whether to change the contents of said first datafield, and a changing procedure for changing the contents of said firstdata field in dependence on said decision procedure, in said receivingnetwork entity, sending a feedback message to said sending networkentity after having received said data unit, said feedback messagecontaining information related to the receipt of said data unit, andincluding in said feedback message information that indicates to saidsending network entity that no network entity was identified in saidfirst data field of said data unit if said network entity identificationinformation in said first data field identifies no network entity atall, or it is determined that the data unit has not passed the networkentity identified by the network entity identification information insaid first data field, and otherwise including in said feedback messageinformation that indicates to said sending network entity the identityof the network entity identified in said first data field.
 19. Themethod according to claim 18, wherein said sending network entity, afterhaving received said feedback message, sets in said first data field ofa data unit to be sent to said receiving peer that no network identityis identified if the information in said feedback message indicates tothat no network entity was identified in said first data field of saiddata unit received at the receiving network entity, and otherwise setsthe identity of the network entity identified in said feedback message.20-35. (canceled)
 36. A sending network entity for transmitting a dataunit arranged in accordance with a predetermined communication protocolover a plurality of network entities, said network entities operatingaccording to said predetermined communication protocol, from saidsending network entity to a receiving network entity over one or moreforwarding network entities, comprising: a data unit generator forgenerating said data unit and providing in said data unit a first datafield arranged to contain network entity identification information,said first data field being different from a forwarding data fielddesignated by said communication protocol to contain information to beused by forwarding network entities for forwarding said data unit to thereceiving network entity, said first data field being defined such thata given network entity that reads the first data field can at least makea decision on the basis thereof whether said given network entity isidentified or not.
 37. The network entity according to claim 36, whereinsaid data unit generator is furthermore arranged in such a way that saidfirst data field is defined such that a given network entity that readsthe network entity identification information can make a decision on thebasis thereof whether no network entity at all is identified by saidfirst data field.
 38. The network entity according to claim 37, whereinsaid data unit generator is furthermore arranged in such a way that saidfirst data field is defined such that if no network entity at all isidentified, said first data field is set to a predetermined first datafield default value.
 39. The network entity according to claim 36,wherein said data unit generator is furthermore arranged to include insaid data unit information directed towards a network entity identifiedin said first data field.
 40. The network entity according to claim 36,wherein said data unit generator is furthermore arranged in such a waythat a network entity identified in said first data field is associatedwith the fulfillment of a predetermined condition with respect to othernetwork entities involved in the transmission of data units from thesending network entity to the receiving network entity, said data unitgenerator comprising an element for determining which information to setin said first data field.
 41. The network entity according to claim 40,wherein said element for determining which information to set in saidfirst data field comprises is arranged to extract said information fromone or more feedback messages received by said sending network entityfrom the receiving entity, said one or more feedback messages relatingto the transmission of previous data units from said sending networkentity to said receiving network entity.
 42. The network entityaccording to claim 40, wherein said predetermined condition is theproviding of the smallest amount of transmission capacity to saidtransmission between said sending network entity and said receivingentity, among the network entities involved in the transmission of dataunits from the sending network entity to the receiving network entity.43. The network entity according to claim 36, wherein said data unitgenerator is furthermore arranged to provide in said data unit a seconddata field arranged to provide information on whether a network entityidentified in said first data field has been passed or not by said dataunit, said second data field being independent of said first field. 44.The network entity according to claim 36, wherein said data unitgenerator is furthermore arranged in such a way that said network entityidentification information comprises a unique identifier, each networkentity being assigned its own identifier.
 45. The network entityaccording to claim 36, wherein said data unit generator is furthermorearranged such that said data unit comprises a count value, and to setsaid count value to a predetermined initial value, where said networkentity identification information comprises a count compare value of asame format as said count value.
 46. The network entity according toclaim 36, wherein said data unit generator is furthermore arranged toprovide in said data unit a third data field arranged to contain adesired transmission volume parameter, and to set a desired transmissionvolume parameter in said third data field of said data unit.
 47. Thenetwork entity according to claim 46, wherein said transmission volumeparameter is a data amount value or a data rate value. 48-83. (canceled)84. A method of controlling a receiving network entity for receiving adata unit arranged in accordance with a predetermined communicationprotocol, said network operating according to said predeterminedcommunication protocol, said data unit being sent from a sending networkentity to said receiving network entity over one or more forwardingnetwork entities, said data unit having a first data field arranged tocontain network entity identification information, said first data fieldbeing different from a forwarding data field designated by saidcommunication protocol to contain information to be used by forwardingnetwork entities for forwarding said data unit to the receiving networkentity, said first data field being defined such that a given networkentity that reads the first data field can at least make a decision onthe basis thereof whether said given network entity is identified ornot, and furthermore being defined such that a given network entity thatreads the network entity identification information can make a decisionon the basis thereof whether no network entity at all is identified bysaid first data field, said method comprising: sending a feedbackmessage to said sending network entity after having received said dataunit, said feedback message containing information related to thereceipt of said data unit, and including in said feedback messageinformation that indicates to said sending network entity that nonetwork entity was identified in said first data field of said data unitif said network entity identification information in said first datafield identifies no network entity at all, or it is determined that thedata unit has not passed the network entity identified by the networkentity identification information in said first data field, andotherwise including in said feedback message information that indicatesto said sending network entity the identity of the network entityidentified in said first data field. 85-86. (canceled)
 87. A networkentity for receiving a data unit arranged in accordance with apredetermined communication protocol, said data unit being sent from asending network entity to said receiving network entity over one or moreforwarding network entities, said data unit having a first data fieldarranged to contain network entity identification information, saidfirst data field being different from a forwarding data field designatedby said communication protocol to contain information to be used byforwarding network entities for forwarding said data unit to thereceiving network entity, said first data field being defined such thata given network entity that reads the first data field can at least makea decision on the basis thereof whether said given network entity isidentified or not, and furthermore being defined such that a givennetwork entity that reads the network entity identification informationcan make a decision on the basis thereof whether no network entity atall is identified by said first data field, said receiving networkentity comprising: a data unit receiver for receiving said data unit, amessage generator for generating a feedback message to be sent to saidsending network entity, said feedback message containing informationrelated to the receipt of said data unit, said message generatorcomprising an element for including in said feedback message informationthat indicates to said sending network entity that no network entity wasidentified in said first data field of said data unit if said networkentity identification information in said first data field identifies nonetwork entity at all, or it is determined that the data unit has notpassed the network entity identified by the network entityidentification information in said first data field, and otherwiseincluding in said feedback message information that indicates to saidsending network entity the identity of the network entity identified insaid first data field and a message output for outputting said feedbackmessage.